-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculate mass budgets online #38
base: develop
Are you sure you want to change the base?
Conversation
Passes and fails same baseline comparisons as PR #37:
|
25e5d2d
to
a6c5c9d
Compare
I have been testing this on Badger in Use the plot_mass_balance.py script in this PR for analysis: MPAS-Dev/MPAS-Tools#464 |
2eb3add
to
b76abbc
Compare
Force-push from 2eb3add to b76abbc was a rebase onto MALI-Dev develop, since quite a few changes have been merged since I started this branch. In case I made any errors while handling merge conflicts during rebase, I created a local backup branch on Badger called |
b76abbc
to
31a4999
Compare
43bda37
to
eba9c09
Compare
c648a08
to
8fe44f0
Compare
250c916
to
a9ece7d
Compare
Add grounded and floating masks that are used for the mass budget calculation and are different from the masks in cellMask. Currently, the only difference is that the grounded mask includes floating non-dynamic cells adjacent to grounded ice. The grounded masks will eventually also include floating ice over subglacial lakes, but that requires flood_fill to be moved from li_calving to a shared routine, so that will come in a future commit. In preparation for that, add domain variable in calls to li_calculate_mask.
Also redefine applied surface and basal mass balance fields based on new grounded and floating masks for mass budgets.
Add variables to distinguish between grounded and floating components of calving in mass budgets.
Add grounded and floating faceMeltingThickness components for calculating mass budgets. Also fix implementation of parsing grounded and floating calvingThickness components, which needs to be done after calvingThickness is applied but before the masks are updated.
Also account for grounded and floating components of calving and face melting. It's still not clear what to do about VAF.
Zero out grounded and floating mass budget masks each time li_calculate_mask is called, to avoid inheritting values from previous steps. Also fix the calculation of total grounded and floating face-melting fluxes in global stats.
Add a very short subroutine update_calving_budget that is called to recalculate groundedCalvingThickness and floatingCalvingThickness after calvingThickness is applied and before masks are updated. Also treat grounded and floating calving specially within the remove_icebergs and remove_small_islands routines to deal with the face that calvingThickness is updated multiple times per timestep. Thus, it is okay for a cell to have both nonzero groundedCalvingThickness and floatingCalvingThickness.
…ckness Instead of cellMask before and after advection, use groundedMaskForMassBudget and floatingMaskForMassBudget before and after advection to calculate groundedToFloatingThickness. This prevents the switch between floating non-dynamic cells and grounded cells being registered as ice grounding, which was causing groundedLineMigration to be the wrong sign in testing on the Humboldt domain.
Calculating grounding line flux after advection led to double (or triple?) counting between GL Flux and GL Migration Flux (and maybe SMB as well). Calculate grounding line flux before advection, smb, and bmb instead.
Update groundedToFloatingThickness whenever masks are updated to account for cells changing between masks when face-melting and calving are applied, and not just when sfcMassBal, basalMassBal, and advection are applied, as was the case previously.
Add halo updates for mass budget masks after calling li_calculate_mask. This did not help close the budget, but in case it is correct I don't want to lose the work. Committing and then reverting.
This reverts commit ff97c4e. The changes in that commit did not help close budgets, but they may be helpful at some point.
The cycle statement used to exit a loop over neighbors when calculating the grounding line and adding non-dynamic floating fringe to the grounded mask was inadvertently outside the relevant if-statement.
Use floatingMaskForMassBudget to define which cells are calving when using config_calving = 'floating'. This is because floating non-dynamic cells adjacent to grounded cells should not really be considered part of the ice shelf.
Use floatingMaskForMassBudget and groundedMaskForMassBudget to partition basal mass balance between grounded and floating.
Use a local variable dCalvingThickness to update the calving budget each time calving is applied. The variable calvingThickness is now not used directly to modify thickness, but calculated by summing dCalvingThickness throughout a time step. This might lead to issues with halo updates because dCalvingThickness is always an allocatable array. If so, it will need to either be made a Registry variable or an MPAS allocatable scratch array.
Clean up a few items after rebasing, including changing a few instances of 'flood_fill' to 'li_flood_fill', an instance of 'nCellsSolve' to 'nCells', and removing cellMaskTemporaryField from li_advection_thickness_tracers.
Update grounded and floating calving budgets incrementally, which is required to close budget.
Fix a few small issues after rebasing onto MALI-Dev/develop
Clean up after rebase, again
Fix dCalvingThickness dimension in remove_small_islands. Must be nCells rather than nCellsSolve in size.
Grounded and floating components of sfcMassBal were using the mass balance mask fields, while basalMassBal components used cellMask. Make both of them use mass balance masks.
Fix accidental doubling of faceMeltingFlux when calculating global stats.
Update layerThickness halos after advection. This reduces the error in a test with 500 m/yr face-melt, so it seems to be necessary, but it does not solve the issue entirely.
Make grounding line flux calculation consistent with FCT advection. Also update edgeMask halos before calculating grounding line flux.
Move face-melting after last velocity solve in RK loop. This is necessary to close mass budgets when using face-melting.
Clean up after rebase following Runge-Kutta merge
Add cellMaskTemporary back to Registry for use in calving.
Loop over nEdgeSolve instead of nEdges when calculating GL flux. Looping over nEdges will give an error resulting from grounding line thickness <= 0 when the grounding line is at the domain boundary.
…ckness Calculate grounding line flux after advection but before updating thickness, which is required to close mass budgets.
Fix a few minor issues that were not caught during the rebase.
fe5b000
to
0e6025e
Compare
…calving thickness Remove block of old code that was inadvertently overwriting grounded and floating calving thickness after they were calculated incrementally.
Replace the allocatable array dCalvingThickness with a Registry variable incrementalCalvingThickness, and update halos after calling li_apply_front_ablation_velocity and before subtracting from ice thickness.
This builds on PR #37 to calculate mass budgets online rather than estimating them in arduous post-processing that requires verbose output. This adds binary masks
groundedMaskForMassBudget
andfloatingMaskForMassBudget
, which are used to calculate the grounded and floating components of the mass budget. Currently, non-dynamic floating cells adjacent to at least one grounded cell are added to the grounded mask and removed from the floating mask.We also will eventually want to add ice floating over subglacial lakes to the grounded mask, which is not done in this PR. However, that likely requires moving the flood fill routine out of
li_calving
and into its own module insrc/shared
, or perhaps into a subroutine ofmpas_li_masks.F
. Calling the flood fill routine many times during a timestep may be rather expensive, so I think that can wait until these changes are tested and merged. The subglacial lakes correction is likely small for most cases, and may not be worth the extra expense in the end.Finally, this does not account for flux through the lateral boundaries of the domain. In use cases to-date, this has been zero, but that is not necessarily the case in general. I think that can be added when it is needed, and therefore I have not included it here.